Collections of data called databases are well known. Computer systems which can be used by multiple users are also well known. When more than one user on a multi-user system attempts to access a database, problems may arise. If one user is reading from the database ,while another user is writing to the database, the data integrity of the data read by the first user is suspect. If two users are attempting to write data to the database, what is actually written is unpredictable and so data integrity is suspect. To minimize these and other data integrity problems, locking schemes were implemented, whereby only one user at a time was allowed to access the database.
Locking a database meant that, whenever a user was reading from or writing to the database, only that user was allowed to access that database, while all other users were locked out. Thus, the problem of one user writing data to a database while another prior user is reading the same data from the database was eliminated. The problem of two users simultaneously writing to a database was also eliminated.
However, locking still did not solve all data integrity problems. For example: User one reads from a database; User two writes data into the same database; and then, user one writes data back into the database. User one may have overwritten the data which user two had written into the database without either user knowing that the data had been altered by the other.
In addition to data integrity problems, locking created system bottlenecks which severely impacted overall system performance, even in a small system with a small number of users. A single user could monopolize a database by gaining access and holding it locked. Other users were forced to wait for access until that first single user released the lock on the database. After the first user released the lock, a second user was free to gain access to the database and monopolize it just as the first user had. That time spent idly waiting was unproductive, wasted and, therefore, impaired system performance. For a larger system with a large number of users attempting to access the same database, the effective result was the same regardless of whether a single user was monopolizing the database. That was because even if no single user attempted to monopolize a single database, the aggregate time spent by all of the users attempting to access the database meant that each user spent a significant amount of time idly waiting for a turn in accessing the database.
In order to address this locking problem and to improve multi-user system performance by reducing the amount of time each user spent waiting for the same database, locks were distinguished based on the type of user access to the database. Thus locks were distinguished as read locks or write locks. A user having a read lock merely prevented another user from writing to the database, while allowing other users to obtain read locks and, concurrently, to read from the same database. A user having a write lock excluded all access by other users until the user having the write lock released the write lock. A system having read locks and write locks to achieve concurrency is also known as "several readers and one writer" system.
This "several readers and one writer" system was inefficient for database applications wherein many users use the same data and, therefore, each user maintains a private copy of the database. One way in which the "many readers and one writer" system was inefficient was that building such a database was slow because only one user at a time could write data to the database in order to update the database. First data was written by the user to the user's private copy. Next, the user transferred the updated private copy to a central master copy of the database. Then the updating user notified every other user of the update. Finally, each user copied the updated master copy into the user's private copy. The next user, wishing to update the database, repeated the steps taken by the previous user in updating the database. A user writing to the database was given a write lock which precluded other users from even reading the database during the write.
When a database is organized as a table, often each database user maintains a private copy. Databases organized as tables and called relations are described in C.F. Date, An Introduction to Database Systems, 4th edition; Addison-Wesley, 1986. A relation has rows called tuples and columns. Each column has a unique name called the column's attribute. Each element in a tuple (or row) is called an item. Each item is identified by the attribute for the column in which it resides. If each tuple has an item or group of items which uniquely identify it, e.g., a row number, then the identifying item(s) is (are) called the tuple's key. If the key is a group of items, then the group is called a composite. Typically, whenever any user modified a private copy of a table, that user had to notify other users that the table was modified, and then send a copy of the altered database to each user. Consequently, each user was then required to update the private copy and, possibly to re-execute calculations or instructions that the user had already executed on the data in the prior copy. Because, very often, each user was only interested in a small subset of the data in an entire table, alterations made to a part of the table by one user might not affect most of the other users. However, regardless of whether alterations to a table affected a user's area of interest, every user holding a private copy was required to update it. Thus, it was more likely than not that the majority of users were unnecessarily forced to update a private copy which wasted valuable computer time and resources. Furthermore, this waste was geometrically proportional to the size of the table and the number of concurrent users. This geometric increase results because every user is required to store a large table each time even a single item in one of the private copies is altered.
Also, as the number of users and the size of the table increase, it is increasingly likely that alterations to the table made by one user would not affect every other concurrent user. Since for a very large database, each user, very likely, is using only a portion of the table, other concurrent users, very likely, also were using different portions which would not include an altered portion. Thus, forcing every user to update or store an updated private copy of a large table regardless of whether the user is affected by the update wasted a significant amount of computer time and resources.
These problems are especially acute in designing highly complex, dense, integrated circuit chips wherein hundreds of designers (users) require concurrent access to design data stored in a single table. Allowing a single user to lock the table during a write delayed all of the other users. Further initially creating the table was slow because, although each of the hundreds of users could create part of the data simultaneously, e.g., one row, only one user at a time could store the data created. Data was stored in the table by copying the table, altering the copy and then storing the altered copy. So, to store data from hundreds of users, the table had to be copied, altered and stored hundreds of times. Each user had to wait for a turn to update the table. Sequentially storing data in the table was both inefficient and time consuming. It was also inefficient to prevent users from reading data which may remain unaltered even after the table is updated.